Hard-cores are often used in ASICs. The hard-core provides guaranteed functionality, such as signal processing. By preventing any changes to the core circuit, the operation of the core will always be the same. The peripheral circuits can be designed to interact with the core to provide the application specific functionality. The precise design of the core is supplied as a “hardmacro” (e.g. a fixed physical circuit layout including a fixed netlist), which can be combined with designs of the peripheral circuits from a different designer. The functionality of the combined circuit design can be synthesised and tested before the circuit is physically manufactured. However, it is not possible to alter any part of the hardmacro.
When testing integrated circuits after manufacture, a known common approach is socalled scan chain testing. In addition to normal circuit paths, the internal registers (flip-flops) in the integrated circuit can be coupled in a test mode to form a serial scan chain path. Data can be clocked into, or out from, the registers on the scan chain path, which act as a single shift register. For scan chain testing, a hardmacro typically has a scan chain line which can be coupled to a corresponding scan-chain path of the peripheral circuits outside the core.
The scan chain is very sensitive to clock-skew between the clock signals applied to the different registers in the scan chain, as this can easily cause a hold-time violation in one or more receiving registers. The sensitivity to skew is magnified with a hardmacro core (or a hard-core), since the clock signals for the peripheral circuits are routed along completely different clock paths (or branched clock trees) outside the core, compared to the clock signals routed inside the core. This problem is illustrated in FIGS. 1 and 2. In FIG. 1, an example first register 10 is illustrated inside a hardmacro core 12, which can be coupled on a scan chain path 14 to a second register 16 in a peripheral circuit outside the core 12. Although both registers 10 and 14 are clocked from the same source 18, the clock signal to the first register 10 is routed on a first clock path 20 within the core 12, and the clock signal to the second register 16 is routed on a completely different clock path 22 outside the core 12 which may be delayed with respect to the internal clock path.
FIG. 2 shows the relationship between the outputs of the registers 10 and 16 when clocked with the respective clock signals. In FIG. 2, the arrows show how the edges of the clock pulses trigger the outputs from the registers with respect to their inputs. For the first register 10 it can be seen that the output (Hardmacro scan-out) effectively lags the input (Scan-in) by almost a complete clock cycle, such that the first register is acting properly as a shift stage in the scan chain. However, the delayed clock to the second register 16 causes a hold-time violation, so that the second register does not capture the previous signal from the first register 10 before the first register output changes; instead it incorrectly captures the output (Hardmacro scan-out) from the first register 10 after the signal from the first register 10 has changed. Therefore, the second register 16 does not act properly as a shift stage, and causes data to be lost in the scan chain.
The above discussion has simplified the problems of applying clock signals in the scan chain. The problem is further worsened in practice because the clock signal paths are usually complicated branched tree paths. Moreover, the clock signal path used during scan chain inputting/outputting is usually different from the clock signal path used during normal operation of the integrated circuit. The test clock paths are only used during initial testing. More effort is therefore devoted to the routing of the normal clock path, as a balanced tree path, to try to control the skew during normal operation of the integrated circuit. In fact, clock skew is inevitable even in the normal clock path, due to noise and to manufacturing tolerances. Since it is impractical to devote as much effort to the routing of the test clock paths (since these are not used during normal chip operation), the degree of clock skew in the test clock paths can be significantly worse.
Design tools are available which can design circuitry to accommodate clock skew between first and second circuit domains provided that the clock skew between the domains is known. The design tools insert a latch in the output of the first domain to act as a buffer for the scan chain signal as it passes from the first domain to the second domain. The latch is clocked by the clock from the first domain, to avoid hold-time violations from the clock of the second domain. Examples of such circuit design tools include FastScan and DFT Advisor from Mentor Graphics Corporation of Wilsonville, Oreg., and Tetramax from Synopsys Corporation of Mountain View, Calif. However, such design tools require the clocks of both the first and second circuit domains to be known, and to be precisely defined, in order to determine whether a latch is appropriate. Such precise information is not always available for hardmacros. An additional problem with such a design tools is that, at the time of designing the peripheral circuit, the design of the hardmacro is already fixed as a pre-released and certified design which cannot be altered. Therefore, the design tool has no way of modifying the hardmacro in the manner described above, and would therefore fail to link the peripheral circuit and the hardmacro in a way that would accommodate clock skew between the circuits. (In fact, the conventional design tool would attempt to include a lock-up latch outside the core, driven by the only clock signal available, namely the skewed clock signal in the peripheral circuit. The latch would then suffer from the same timing problems as those explained above for FIG. 2).
In the absence of any reliable technique for detecting and addressing scan chain timing problems between a fixed hardmacro and a peripheral circuit during the design stage, such timing problems are often only appreciated after the circuit has been physically manufactured. This leads to additional costs and delays while the problem is investigated and resolved by engineers manually. This problem is made worse in practice because the peripheral circuits are designed by different engineers (and different companies) from the original core designers.
Therefore, the technical problem underlying the invention arises from the two-part manner in which hard-core circuits are designed. The core designer is only concerned with the functioning of the core, and not with timing compatibility with peripheral circuits. Ensuring timing compatibility (and all compatibility) is the problem for the designer of the peripheral circuits after the core has been designed and released. However, the designer of the peripheral circuits is dealing with a pre-designed hard-core circuit, and cannot make any changes to the core. He can only design around the core.